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Early  implementations  of  collaboration  technology  facilitated  applica¬ 
tions  such  asjoint  calendar  scheduling  and  groupware1  products  E- 
mail  and  theWorld  WideWeb  provided  thebasic  support  for  thistype 
of  asynchronous  collaboration.  IP  multicast  offers  an  infrastructure  to  sup¬ 
port  a  shift  from  small-scaleand  single-media  collaboration  to  wide-area,  syn¬ 
chronous  multimedia  collaboration  (see  the  sidebar,  "SameTime,  Different 
Place:  Collaboration  on  the  Internet").  In  particular,  support  for  multicast 
technologies  enables  applicationssuch  asdistributed  collaborative  design  or 
distributed  interactivesimulations  where  many  users  share  many  resources 
We  use  the  term  group  coordination  support  to  address  the  services 
required  when  many  users  try  to  access  and  manipulate  objects  synchro¬ 
nously  in  a  shared  workspace.  A  collective  of  users  connecting  from  var¬ 
ious  locations  to  work  together  on  shared  data  or  using  conferencing  tools 
to  communicate  ideas  iscalled  asession.  Sessionscan  consist  of  individ¬ 
uals  or  multicast  groups  sharing  specific  interests.  Group  coordination 
services  complement  group  membership  and  communication,  and  entail 
synchronization  of  content  and  activities  in  remote  workspaces  with 
regard  to  time  and  space,  delivery  of  events  and  updates  to  end  hosts  in 
causal  or  total  order,  and  mutual  exclusion  in  resource  access.  Thisapplies 
to  shared  tools,  resources,  and  content  which  are  sensitive  to  time,  order¬ 
ing,  or  concurrent  usage. 

In  this  article,  we  introduce  fundamental  concepts  and  trade-offs  i  n 
group  coordination  support,  focusing  on  thefloor  control  aspect.  Floor 
control  is  particularly  important  for  "tightly  coupled"  sessions,  which 
require  explicit  member  registration  and  follow  a  more  formal  agenda.  We 
will  use  collaborative  visualization  as  an  illustration  of  coordination  issues 
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and  proposea  novel  coordination  mechanism  for 
Internet  collaboration  using  addressing  extensions 
to  current  multicast  technologies. 

SCENARIO 

Consider  a  session  with  many  users  I  inked  togeth¬ 
er  for  the  pu  rpose  of  col  I  aborati  ve  visualization  on 
a  critical  weather  condition.  T  he  information  for 
thissession  is  retrieved  from  a  real-time  database, 
which  receives  data  from  a  global  network  of  sen¬ 
sors  measuring  environmental  conditions.  Some 
researchers  are  interested  in  wind  information, 
whereas  othersform  a  subgroup  analyzing  temper¬ 
ature  data.  Such  subgroups  may  overlap  and  data 
are  to  be  multicast  only  to  its  members.  In  addi¬ 
tion,  researchers  may  want  to  remotely  control  sen¬ 
sor  devices  to  deliver  specific  data,  but  the  devices 
may  not  be  able  to  service  various  requests  at  the 
same  time. 

H  ow  would  scalable,  Internet-widegroup  coor¬ 
dination  need  to  be  designed  to  allow  these 
researchers  to  collectively  visualize  their  data  and 
avoid  resource  contention? 

FLOOR  CONTROL 

Floor  control  is  a  component  of  group  coordina¬ 
tion  support  that  prevents  or  resolves  resource  con¬ 
tention.2  Working  in  a  network-centric  way  with 
continuous  media  and  short-term  permissions,  it 
complements  access  control  on  static  files  in  oper¬ 
ating  systems,  concurrency  control  for  transaction 
management  in  database  systems,  and  mutual 
exclusion  mechanismsfor  resource  control  in  dis¬ 
tributed  systems.  Asweenvision  it,  a  general  floor- 
control  architecture  is  a  distributed,  reusable,  and 
transparent  service  below  the  application  layer, 
involving  thefollowing  entities: 

■  human  users  or  their  system  agents,  who  aggre¬ 
gated  multicast  groups  and  assume  variousses- 
sion  roles  such  as  moderator,  panel  member,  or 
lecturer; 

■  a  collection  of  multimodal  resource  objects  in 
the  shared  workspace,  which  can  be  hardware 
devices  at  certain  end-hosts  or  application  con¬ 
structs  such  as  graphical  widgets  being  replicat¬ 
ed  at  each  host.  Resources  can  be  shared  at  var¬ 
ious  levels  of  granularity,  for  example,  in  the  case 
of  a  video  stream,  as  an  entire  video  sequence,  a 
scene  with  several  frames,  a  single  frame,  or 
parts  of  a  frame. 

System  support  for  floor  control  may  not  be  need¬ 


ed  for  a  small  shared  whiteboard  session  or  video 
conference,  where  social  cues  suffice  to  coordinate 
joint  activities  with  a  "free-for-all"  floor  policy. 
H  o wever,  u sers  may  have  difficulty  achieving  con¬ 
sensus  in  large  sessions,  when  hosts  are  heteroge¬ 
neous,  network  delay  is  high,  shared  toolsor  infor¬ 
mation  are  more  complex,  or  simply,  users 
experience  cultural  differences  and  social  protocols 
are  misunderstood.  In  these  cases,  floor  control 
helps  to  establish  a  sharing  etiquette,  fostering  orga¬ 
nized  turn-taking.  From  a  system  perspective,  floor 
control  allows  more  effective  allocation  of  band¬ 
width,  because  data  packets  are  sent  only  between 
hosts,  which  are  authorized  to  send  and  to  receive. 

Floor  control  can  bedeployed  with  oneormore 
human  moderators  in  a  session,  or  by  the  system 
using  prediction,  filtering,  and  reservation  to 
respond  to  floor  requests  for  a  shared  resource.  Floor 
control  uses  coordination  primitives  called  floorsto 
place  short-lived  permissionson  resourcesto  medi¬ 
ate  concurrent  access  For  ©cample,  floorsfor  a  video 
stream  can  be  "open,"  "pause,"  "edit  frame,”  or 
"replay."  Floors  need  to  be  requested  and  granted  in 
a  session-wide  contention  scheme.  An  individual 
usage  period  for  a  floor  is  called  a  turn,  and  the 
switching  of  control  iscalled  turn-taking. 

Various  methods  to  implement  floor  control 
have  been  proposed  within  the  past  10  years.  T  he 
differences  in  these  implementations  can  be  nar¬ 
rowed  down  to  three  criteria: 

■  token  passing  between  hosts,  or  permissionsas 
local  markers  at  each  host  are  used  to  indicate 
thecontrol  state  for  a  remote  resource; 

■-  control  iscentralized  and  static,  centralized  but 
roving  among  hosts,  or  fully  distributed; 

■  the  infrastructure  used  to  disseminate  control 
information  among  hosts,  which  iscommonly 
a  bus,  star,  ring,  or  tree  geometry. 

GROUP  COORDINATION 
AND  IP  MULTICAST 

In  group  coordination,  control  messages  must  be 
routed  among  hosts  in  the  control  tree  built  for 
managing  session  interactions,  as  in  IP  Multicast, 
and  failed  control  directives  must  be  retransmitted, 
similar  to  how  packet  losses  must  be  recovered  in 
reliable  multicast.3 

Recent  collaborative  applications  use  thelP  M  ul- 
ticast  model  for  dissemination  of  streams  This  model 
alone  seems  not  sufficiently  powerful  for  the  spec¬ 
trum  of  distributed  multimedia  applications  To  see 
why  not,  let's  look  first  at  how  I P  M  ulticast  works 
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Figure  1.  Snapshot  of  a  virtual  workspace  shared 
by  users,  A,  B,  and  C,  from  three  distinct  multicast 
groups,  MG1,  MG 2,  and  MG 3,  in  one  session. 

The  three  users  form  a  multicast  coterie,  MC. 


A  multicast  tree  is  either  a  shortest  path  or  a 
shared  tree.  A  shortest  path  tree  is  a  directed  tree, 
where  one  source  reaches  all  members  of  the  mul¬ 
ticast  group;  a  shared  tree  is  constructed  for  a  group 
and  shared  by  all  sources.  The  multicast  delivery 
tree  is  constantly  pruned  or  extended  by  a  multi¬ 
cast  routing  protocol  such  asDVM  RP,  PI M  ,  or 
CBT  (for  a  general  referenceon  routing  protocols, 
see  H  uitema4).  Thus,  the  tree  reflects  the  current 
state  of  subscriptionsto  multicast  groups  and  pres- 
enceof  adjunct  network  resources  Source  trees  are 
suited  for  a  scenario  where  one  source  incites  a 
long-lived  transmission  to  other  session  members, 
and  no  further  individual  source treesin  thesession 
must  be  built. 

Weconsider  again  the  collaborative  visualization 
session  S  illustrated  in  Figure  1.  The  resourced 
under  contention  is  a  data  grid  with  a  shared  tele¬ 
pointer,  and  the  grid  can  be  rendered  differently 
depending  on  model  assumptions  and  specific 
parameters.  For  example,  it  might  display  wind 
velocities  or  a  three-dimensional  temperature  field. 

Three  multicast  groups,  MG1,  MG 2,  and 
M  G  3,  represent  researchers  in  a  shared  workspace 
with  different  interests  in  the  data.  Among  them, 
users  A,  B,  and  C  form  a  multicast  subgroup  M  C, 
with  a  special  interest,  for  example,  in  wind  data. 
With  the  standard  IP  M  ulticast  model,  any  wind 
data  renditions  made  by  user  C  would  be  visible 
not  only  to  subgroup  membersA  and  B,  but  also 
to  all  the  members  of  groups  M  G 1,  M  G  2,  and 


M  G  3.  T  he  resulting  transfer  sends  content  that  not 
all  session  members  are  interested  in  and  wastes 
network  and  host  resources 

The  researchers  in  M  C  could  form  an  extra  mul¬ 
ticast  group,  but  if  manysuch  intermediate  results 
need  to  be  created,  it  is  more  elegant  and  transpar¬ 
ent  to  allow  subgroups  of  multicast  groups  to  "sub¬ 
cast"  data  on  a  per-packet  basis.  For  such  highly 
interactive  group  work,  the  per-source  tree  model 
would  require  hoststo  join  a  new  tree  per  turn  and 
subsequently  tear  down  the  temporary  multicast 
tree,  which  is  impractical. 

In  the  shared-tree  model,  onesingletreeiscon- 
structed  in  the  beginning  of  a  session,  and  hosts 
join  the  session  by  being  added  into  the  tree.  When 
a  host  becomes  floor  holder,  it  transmits  its  data 
either  to  its  children,  if  the  target  hosts  arelocated 
in  its  subtree,  or  to  its  parent  host  if  the  target  is 
located  elsewhere  in  the  tree.  FI  ence,  each  trans¬ 
mission  involves  only  as  many  hostsasthebranch- 
i  n g  factor  of  th e  tree  i  n d i  cates.  Stal e  I  i  n  ks  o r  fai  I  ed 
hosts  can  be  handled  by  using  one  of  the  many 
heuristics availablefor  reconstructing  and  optimiz¬ 
ing  shared  trees6 

Thissubcasting  model  motivatesa  refined  intra¬ 
group  addressability  service  to  selectively  multicast 
control  information  and  data  to  subgroups  on  a 
per-turn  or  per-packet  basis  I P  M  ulticast  lacks  such 
addressing  information  that  would  allow  elements 
of  multicast  groupsto  confer  with  each  other  with¬ 
out  affecting  the  session  as  a  whole.  Thus,  a  floor¬ 
holding  host  can  only  address  an  entire  group. 

INTEGRATION  WITH  RELIABLE 
MULTICAST 

We  have  developed  away  to  address  thislimitation 
by  integrating  results  from  recent  work  on  extend¬ 
ed  multicast  services5  into  group  coordination  sup¬ 
port.  In  contrast  to  earlier  systems  supporting 
group  coordination  in  a  unicast  or  broadcast  com¬ 
munication  style,  we  assume  that  hosts  in  our  sys¬ 
tem  usemulticast  routing  and  reliablemulticast  to 
disseminate  control  primitives 

We  propose  to  supply  floor  control  as  a  modu¬ 
lar  service  above  thetransport  layer  and  to  provide 
addressing  extensions  to  reliable  multicast  that 
allow  for  self-routing  of  control  messages  in  a  single 
shared  control  tree.  By  mirroring  the  end-to-end 
multicast  tree,  a  floor-control  protocol  need  not 
maintain  its  own  logical  control  infrastructure.  This 
approach  also  allows  for  an  unlimited  number  of 
subgroups  within  a  multicast  group,  overlapping  of 
groups  without  delivery  conflicts,  and  floor-con- 
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SAME  TIME,  DIFFERENT  PLACE:  COLLABORATION  ON  THE  INTERNET 


Most  collaborative  work  conducted  today  via  the  Internet  is 
asynchronous  in  nature,  as  with  e-mail,  bulletin  boards,  and 
W  eb  pages.  Tools  for  synchronous  communication,  such  as 
the  Internet  relay  chat  (IRC),  M  ulti-User  Dungeons,  and 
object-oriented  MUDs  (MO Os),  are  largely  text-oriented. 
Commercial  groupware  tools  such  as  Lotus  N  otes,  N  ovell 
Groupwise,  M  icrosoft  N  etM eeting,  0 'Reilly  Webboard,  or 
ICQ  are  based  on  replication  and  transactive  store-and- 
forward  of  shared  information  across  a  centralized  server. 

The  ITU  videoconferencing  standard  H.320  is  based  on 
centralized  conference  mediation  in  a  circuit-switched  envi¬ 
ronment  with  little  provision  for  group  coordination.  M  any 
groupware  tools  include  floor  control,  but  the  implementa¬ 
tions  are  generally  monolithic,  proprietary,  and  unscalable. 

There  is  no  general  framework  for  group  coordination 
atthis  time,  but  there  are  several  individual  approaches. 
You  can  check  the  following  examples  out  on  the  Web: 
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COLLABORATIVE  WORK  UNKS 


■  The  REIN  AS  project  at  UC  Santa  Cruz  is  a  distributed 
measurement-gathering  system  for  environmental  data, 
which  supports  both  collaborative  and  single-user  work  for 
analysis  and  visualization  with  the  Cspray  application.1 

■  The  MINT  architecture  implements  distributed  floor 
control  in  a  lightweight  multicast  model,2  and  control 
messages  are  communicated  multiply  among  floor 
agents  to  achieve  reliability. 

■  The  Web-based  collaboration  system,  JETS,  implements 
floor  control  through  Java  applets  that  lock  resources  at 
session  servers.3 

■  The  Berkeley  MASH  project  revamps  Mbone  tools 
based  on  an  active  service  model  using  floor  control  to 
adapt  bandwidth  share  to  receiver  interest.4 

■  G  roupkitis  a  toolkitfrom  the  University  of  Calgary,  based 
on  Tcl/Tk  and  geared  toward  building  small-scale 
applications  for  synchronous  group  work. 


ACM  SIGGROUP  •  www.acm.org/  sigg roup/ 

European  Telework  Online  •  www.eto.org.uk/ 

Groupkit  •  www.cpsc.ucalgary.ca/  grouplab/  groupkity 
Groupware  Links  •  www.usabilityfirst.com/  cscw.html 

Human-Computer  Interaction  (HCI)  Sites  • 

www.acm.org/  sigchi/  hci-sites/ 

International  Multimedia  Teleconferencing  Consortium  • 

www.imtc.org/ 

International  Telecommunication  Union  •  www.itu.int/ 

IP  Multicast  Initiative  •  www.ipmulticast.com/ 

JETS*  www.mcrlab.uottawa.ca/jets/ 

MASH  •  www-mash.cs.berkeley.edu/  mash/ 

MINT  •  www.fokus.gmd.de/  research/  cc/  g lone/ 
products/  mint / 

Multimedia  Communications  Forum  •  www.mmcf.org/ 
REINAS  •  www.cse.ucsc.edu/  research/  reinas / 
Telecooperation  Links  • 

www.telekooperation.de/  cscw/  cscw-links.html 


trolled  anycasting.  Furthermore,  using  reliable  mul¬ 
ticasting  to  disseminate  control  directives  ensures 
proper  delivery  and  consistency  of  floor  states  dur- 
ingasession. 

The  principal  idea  is  to  map  the  properties  of 
floor-control  services  onto  the  reliable  multicast 
tree.  While  maintaining  a  state  table  tracking  cur¬ 
rent  floor  properties  at  various  hosts  in  the  session, 
a  floor-control  protocol  taps  into  the  reliable  mul¬ 
ticast  host  tableto  infer  about  host  connectivity  and 
forwards  information  to  members  of  a  multicast 


group  or  session.  Similar  to  the  aggregated  for¬ 
warding  of  packets  in  tree- based  reliable  multicast, 
control  directives  are  sent  out  only  to  the  hosts  that 
are  immediate  children  or  parents  in  the  control 
tree.  This  hierarchical  floor  control  can  be  inte¬ 
grated  with  any  tree-based  reliable  multicast  proto¬ 
col,  such  asRM  TP,TM  TP,  or  the  Lorax  protocol.6 

The  logical  infrastructure  used  to  route  control 
messages  is  coherent  with  the  underlying  reliable 
multicast  infrastructure  and  to  an  approximate 
degree  with  the  multicast  routing  tree.  T  his  means 
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Figure  2.  Aggregated  dissemination  of  floor  information  across  the 
control  tree  based  on  host  labels. 


fix  comparisons  Ifthe  target  host  label  is  a  prefix  of 
thesource,  the  target  host  isachild  of  thesource, 
and  the  message  will  be  routed  to  thischild  host  and 
possibly  forwarded  further.  Otherwise,  the  packet 
will  be  sent  up  to  the  source’s  parent,  terminating  the 
forwarding  process  when  labelsmatch. 

One  drawback  of  such  labeling  is  that  the  con¬ 
catenation  of  labels  will  result  in  long  tags  for  deep 
trees  with  a  high  branching  factor.  A  solution  to 
this  problem  is  to  stack  labels  hierarchically  corre¬ 
sponding  to  the  various  subgrouping  levels,  how¬ 
ever,  it  is  unlikely  that  a  collaborative  session  will 
reach  such  scope. 

Aggregated  Control 

T  he  core  operational  parameters  of  a  floor-control 
protocol  are 


that  there  is  no  need  to  set  up  and  maintain  asep- 
arate  logical  control  geometry  for  group  coordina¬ 
tion  purposes.  Furthermore,  asa  unifying  delivery 
medium,  a  single  shared  tree  simplifies  the  mixing 
and  orchestrated  usage  of  many  media  by  multiple 
parties  in  a  session.  Finally,  control  messages  are 
delivered  in  an  aggregated  manner.  T  hat  is,  if  sev¬ 
eral  children  of  a  host  in  the  tree  submit  the  same 
control  directives,  the  parent  node  only  forwards 
one  such  directive,  and  likewise,  if  nearby  nodes  are 
able  to  satisfy  a  specific  control  directive— say 
retrieval  of  updates  to  resource  states— then  the 
closest  nodeto  the  requesting  nodewill  satisfy  this 
request  without  affecting  further  nodeson  the  path 
to  the  target  node  or  that  node  itself. 

FI  ierarchical  fulfillment  of  requests  and  state 
updates thusgreatly  reduces  control  traffic  in  a  ses¬ 
sion  and  allowsa  host  to  interact  precisely  only  with 
other  hosts  of  interest,  without  having  to  alter  the 
multicast  tree. 

Addressing 

0  n-tree  hosts  are  labeled  recursively  with  prefix 
labels  top-down  from  the  tree  root  with  a  simple 
alphabet  consisting  of  as  many  characters  as  the 
branching  factor  of  the  tree.  Labels  are  assigned  at 
tree  creation  and  need  only  be  reassigned  during  a 
session  lifetime,  if  the  tree  incurs  grave  alterations 
or  damage. 

The  labels  mark  a  host's  position  relative  to  the 
addressi  ng  root  of  the  control  tree,  assumi  ng  that  the 
host  initiatinga  session  becomes  the  root.  Source  and 
target  labels  define  a  unique  path  through  thetree, 
enabling  self-routing  of  control  packets  based  on  pre¬ 


■  a  session  identifier, 

■  a  multicast  group  address, 

■  an  identifier  for  thefloor-controlled  resource,  and 

■  identifiers  for  three  hosts,  the  floor  controller 
(FC ),  thefloor  holder  (FFH ),  and  the  host  send¬ 
ing  a  floor  request. 

FC  allocates  thefloor  to  a  host  as  an  arbiter,  and 
F  H  hasthe  exclusive  right  to  use  the  resource.  Both 
roles  can  coincide  in  one  host.  The  FC  may  either 
be  static  or  roam  among  hosts,  while  F FI  shifts  on 
a  per-turn  basis.  The  floor-holding  time  may  be 
unlimited  or  timed  out. 

To  balance  the  control  load  across  the  system, 
different  hosts  can  become  FC  for  the  various 
floors.  The  address  of  FC  and  FFH  must  be  known 
to  all  other  hosts,  either  by  broadcasting  an  update 
on  the  new  location  after  a  change  or  by  having  the 
nodes  broadcast  requeststo  thesession  or  multicast 
group  handling  thespecific floor. 

Operation 

Consider  again  the  collaborative  visualization 
example.  In  Figure 2,  host  label  information  has 
been  added  to  the  on-tree  nodes  to  allow  for  host 
and  group-specific  aggregation  and  forwarding  of 
floor-control  messages.  Again,  nodeC  isFC  for  the 
floor  to  render  the  data  grid  in  acertain  way.  Labels 
are  used  to  address  only  those  hosts  actively  par¬ 
taking  in  the  current  turn-taking. 

Note  that  the  label  information  used  for  floor 
control  can  be  independent  from  the  labels  used  for 
reliable  multicast,  since  multicast  groups  for  con¬ 
trolled  resource  access  may  differ  from  groups 
involved  in  streaming  and  other  data  transmission. 
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Weassume,  however,  that  this  control  treemirrors 
the  reliable  multicast  tree.  Asa  host  in  a  collabora¬ 
tive  session,  each  node  in  the  tree  needs  to  know 
the  labels  of  those  nodes  with  which  it  shares 
resources  Labels  can  also  be  seen  as  identification 
substitutes  for  hosts,  allowing  for  sharing  of  infor¬ 
mation  without  the  need  to  reveal  actual  IP 
addresses. 

Assume  that  hosts  12, 100,  and  11  contend  for 
thefloor  held  byFC  at  location  101,  knowing  that 
all  request  messages  need  to  be  routed  along  branch¬ 
es  of  the  tree  to  101.  T  he  prefix  property  of  the 
labels  allows  self-routing  of  these  packets  Host  12 
compares  its  label  with  the  target  label.  Its  prefix 
matches(l),  butthesecond  identifier  indicates  that 
theFC  ison  subtree  0.  The  request  packet  is  hence 
sent  upward  to  host  1,  which  compares  its  label  with 
thetarget,  and,  detecting  that  101  isoneof  its  chil¬ 
dren,  it  sends  the  packet  to  host  10  whose  label 
matches  the  prefix  of  101.  This  host  performs  the 
samecomparison,  and  the  packet  ultimately  arrives 
at  FC,  which  finally  grants  thefloor  to  host  12. 

T  h e  fo r ward i  n g  of  co n tro  I  d  i  recti  ves  i  s  aggre¬ 
gated.  M  ultiplerequestsforthesameinformation 
from  different  nodesin  the  tree  are  assembled  in 
thetreein  hop  nodes  on  thepath  to  thetarget,  and 
are  forwarded  combined  orrqected  early.  This  lim¬ 
its  control  traffic  and  unnecessary  processing  of 
requests  that,  for  example,  cannot  be  satisfied  at 
FC.  FC  is  hence  liberated  from  the  need  to  com¬ 
municate  with  every  host  in  thesession,  and  deals 
only  with  relevant  requests  reaching  itfrom  neigh¬ 
bor  nodes  by  self-routing. 

I  n  a  different  model  without  a  moderator  or  FC , 
nodes  could  address  the  current  FH  to  ask  for  the 
floor  following  the  same  principle.  In  this  case,  an 
FH  change  would  have  to  be  multicast  to  all  hosts 
interested  in  thefloor  administered  by  FH  to  update 
them  on  thenew  positional  label  information. 

This  selective  addressing  scheme  allows  nodes 
A,  B,  and  C  to  communicate  and  subcast  their 
floor  control  information  and  data  without  affect¬ 
ing  the  other  users  in  their  multicast  groups, 
M  Gl,  M  G2,  and  M  G3.  In  this  sense,  the  sub¬ 
grouping  mechanism  establishes  lightweight  mul¬ 
ticasting  in  a  session  and  allowsfor  more  reactive, 
fair,  scalable,  efficient  turn-taking  on  multimedia 
resources 

Thisschemaisalso  resilient  because  failure  of  a 
node  only  affects  partitions  of  the  multicast  tree, 
and  a  session  can  still  be  continued  in  separate 
branches  of  the  tree,  or  tree  halves  can  be  merged 
at  a  different  anchor  node. 


PERFORMANCE 

A  comparative  study  by  Pendergast7  on  the  effec¬ 
tiveness  of  groupware  systems  to  handle  multiple 
sessions  and  data  replication  suggested  that  differ¬ 
ent  implementation  methodologies  needed  to  be 
employed  for  effectively  putting  groupware  appli¬ 
cations  to  work  of  varying  purposes  The  study  dis¬ 
tinguished  between  three  models:  central  sequenc¬ 
ing,  distributed  operation,  and  independent 
objects.  H  owever,  the  research  assumed  generic 
state  machines  for  modeling  the  three  application 
types  and  did  not  take  the  network  or  user  into 
account. 

We  recently  compared  social  and  machine-dri¬ 
ven  floor  control  subsumed  under  a  turn-taking 
model  and  evaluated  for  fully  connected  sessions, 
rings,  and  trees.  Results  showed  that  tree-based 
aggregated  management  of  floor  information  in  a 
multicast  context  achieved  better  scalability  and 
efficacy  than  solutions  relying  on  social  mediation 
or  those  operating  in  directly  connected  or  ring- 
based  networks.2 

Attaching  positional  labelsto/V  nodes  impliesa 
storage  cost  of  log2W  bits  If  16  bits  were  used  for 
labels,  thistree  could  accommodateup  to  216  hosts 
in  a  session.  Each  level  in  the  control  tree  adds 
log2D  bitsin  a  tree  of  degree  D.  The  cost  for  serv¬ 
ing  afloor  request  f/sCf=craJ  +  crep  +  cupci„  com¬ 
prising  the  costs  to  send  a  request  to  a  control  node, 
receive  a  response,  and  multicast  an  updateon  the 
new  state.  We  make  a  simple  comparison  for  the 
delay  in  a  unicast,  multicast,  and  aggregated  mul¬ 
ticast  communication  model  under  full  load  (each 
node  sends  a  control  primitive),  assuming  that  the 
host  processing  cost  for  request,  response,  and 
update  packets  is  equal  and  normalized.  The  aver¬ 
age  path  length  between  nodes  is  assumed  to  be  the 
same  for  all  models.  X  represents  the  individual 
processing,  packetization,  and  transmission  over¬ 
head  for  each  type  of  message. 

In  unicast,  the  coordination  delay  incurs/V  -  1 
requests,  replies  from  control  nodes,  and  updates, 
where  N  is  the  current  session  size;  that  is,  Cuc  = 
3(l\l  -  1)  X.  In  multicast,  N  -  1  nodes  send 
requests,  and  thecontrol  node  multicasts  one  reply 
and  one  update  back  to  the  session;  that  is,  Cmc  — 
(N  +l)X. 

In  aggregated  multicast,  floors  are  handled  with¬ 
in  multicast  groupsand  only  the  root  of  a  group  for¬ 
wards  a  composite  request  to  its  parent,  or  responds 
to  group-local  requests,  if  it  holdsthe  information 
locally.  With  K  groups  we  have  on  the  average  G  = 
N/K  members  per  group,  and  per  group  there areG 
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Figure  3. Coordination  cost  for  various  communication  models. 


requests  inside  a  group,  K  aggregated  requests  sent 
to  a  control  node  from  all  groups,  and  one  multi¬ 
cast  response  and  update.  T  herefore,  Camc  =  ((G  - 
1)  +  (K-  1)  +  2)  A  =  (G  +K)A. 

Figure  3  shows  the  average  cost  to  coordinate 
hostsin  sessions  up  to  size N  =1000,  clustered  into 
K  =N/10  groups,  and  a  normalized  transmission 
overhead.  It  elicits  the  benefits  of  aggregated  mul¬ 
ticast  dissemination  of  floor  control  information. 

CONCLUSION 

Research  on  group  coordination  faces  many  open 
problems  such  asscalablesession  management,  reli¬ 
able  and  ordered  multicast,  composableand  het¬ 
erogeneous  collaboration  architectures,  history 
management,  and  novel  multimodal  user  inter¬ 
faces.  For  instance,  floor  control  information  must 
be  conveyed  effectively  through  a  graphical  user 
interface  to  be  acceptable  to  users 

These  research  topics,  known  from  distributed 
systems  and  Web  technology,  will  gain  relevance  as 
more  I  nternet  applications  shift  from  asynchronous 
interaction  to  synchronouscollaboration  with  new 
media  and  input  modalities  Also  of  interest  in  this 
context  are  security  and  anonymity  in  collabora¬ 
tion,  because  receivers  in  I P  M  u I ti cast  need  not 
announce  their  participation  in  a  multicast  group 
to  other  group  members,  and  senders  need  not 
know  the  receiver  set. 

Label-based  group  coordination  solution  is  well 
suited  to  support  such  interaction.  Weare currently 
developing  ajava-based  implementation  ofthecon- 
cepts  presented  here.  ■ 


ACKNOWLEDGMENTS 

This  work  was  supported  by  the  Defense  Advanced  Research 

Projects  Agency  under  grant  F19628-96-C -0038. 

REFERENCES 

1.  C.A.  Ellis,  S.J.  Gibbs,  and  G.L.  Rein,  "Groupware:  Some 
Issues  and  Experiences,"  Comm.  ACM ,  Vol.  34,  No.  1,  Jan. 
1991,  pp.  38-58. 

2.  H  .-P.  Dommel  andJ.J.  Garcia-Luna-Aceves,  "Efficacy of 
Floor  Control  Protocols  in  Distributed  M  ultimedia  Col¬ 
laboration,"  Cluster  Computing,  Vol.  2,  No.  4,  1999,  to 
appear. 

3.  C.  M  etz,  "Reliable M  ulticast:  When  M  any  M  ust Absolute¬ 
ly  Positively  Receive  It,"  IEEE  I  nternet  Computing,  Vol.  2, 
No.  4, July-Aug.  1998,  pp.  9-13. 

4.  C.  H  uitema,  Routing  in  the  I  nternet,  Prentice  H  all,  Engle¬ 
wood  Cliffs,  New  Jersey,  1995. 

5.  B.N .  Levi ne and J. J.  Garcia-LunaAceves,  "Improving Inter¬ 
net  M  ulticast  with  Routing  Labels,"  Proc.  IEEE  Inti  Conf. 
I\l  etwork  Protocols,  Atlanta,  Ga.,  1997,  pp.  241-250. 

6.  B.N  .  Levine,  D.  Lavo,  andJ.J.  Garcia-LunaAceves,  "The 
Case  for  Reliable  Concurrent  M  ulticasting  Using  Shared 
Ack Trees,"  Proc.  ACM  M ultimedia,  Boston,  M  ass.,  Nov. 
1996,  pp.  365-376. 

7.  M  .0.  Pendergast,  "M  ulticast  Channels  for  Collaborative 
Applications:  Design  and  Performance  Evaluation,"  Com¬ 
puter  Comm.  Review,  Vol.  23,  No.  2,  Apr.  1993,  pp.  25-38. 


Hans-Peter  Dommel  is  a  PhD  candidate  at  the  School  of  Engi¬ 
neering,  University  of  California,  Santa  Cruz.  H  is  current 
research  interests  are  networked  multimedia  systems, 
CSCW,  and  ubiquitouscomputing.  H  e received  an  M  S  in 
computer  science  and  theoretical  linguistics  from  theTech- 
nical  Universityof  M  unich,  Germany,  in  1990,  and  an  M  S 
in  computer  engineering  from  UC  Santa  Cruz  in  1994.  H  e 
is  a  member  of  the  IEEE  Computer  Society,  the  ACM  ,  and 
the G  erman  C  omputer  Society  G I . 


J  .J .  G  arcia-Luna-Aceves  is  a  professor  of  computer  engi  neeri  ng 
at  the  U  niversity  of  California,  Santa  C ruz  and  a  visiting 
professor  at  Sun  M  icrosystems  Laboratories.  H  e  received  a 
BS  in  electronic  engineering  from  the  Universidad 
Iberoamericana,  M  exico  City,  in  1977,  and  an  M  S  and  a 
PhD  in  electrical  engineering  from  the  University  of 
Hawaii.  H  e  is  recipient  of  the  SRI  International  Excep¬ 
tional  Achievement  Award  in  1985  for  his  work  on  multi- 
media  communicationsand  again  in  1989  for  his  work  on 
adaptive  routing  algorithms.  H  e  is  a  member  of  the  IEEE 
and  the  ACM  . 

Readers  can  contact  the  authors  at  University  of  California, 
Computer  Engineering  Dept,  Santa  Cruz,  CA  95064,  USA;  e- 
mail  {peter, jj  }@cse. ucsc.edu. 


80  MARCH  •  APRIL  1999  http://COmputer.org/intemet/ 


IEEE  INTERNET  COMPUTING 


